這個系列的題目是「與 Codex 協作打造 Idea Note PWA」。

既然有 AI 可以直接修改專案，照理來說，我只要把需求說清楚，等它把程式寫完就好了。

但事情好像沒有這麼簡單。

如果 Codex 一次改了很多檔案，而我只確認網頁能不能正常打開，卻不知道它改了什麼，那麼下一次發生錯誤時，我大概也不知道該從哪裡找。

更現實一點來說，假如有人問我：

「這段程式為什麼這樣寫？」

我總不能回答：

「因為 AI 寫的。」

所以今天先不急著增加 Idea Note 的功能。我想先替自己建立一套和 Codex 合作的方式。

我以前使用 AI 寫程式的問題

以前遇到不會寫的功能時，我常直接把需求丟給 AI。

得到答案後，只要程式能執行，就先複製進專案。不能執行，再把錯誤訊息貼回去，請 AI 繼續修改。

這種方式偶爾真的很快，但也很容易出現一個問題：功能完成了，我卻沒有跟上修改過程。

尤其當程式碼一次變動太多時，我會開始分不清楚：

• 哪些是原本的程式
• 哪些是 AI 新增的內容
• 哪一段負責目前的功能
• 發生錯誤時應該改哪裡
• 有沒有順便動到不該修改的地方

最後專案看起來像是完成了，實際上卻變得不敢碰。

需求不能只說「幫我做好」

如果我只對 Codex 說：

幫我完成一個筆記 App。

這個範圍其實非常大。

它可能一次加入新增、編輯、刪除、搜尋、儲存和一堆畫面樣式。看起來進度很快，但我要理解的內容也會在同一時間全部堆過來。

所以之後每次請 Codex 修改 Idea Note，我會盡量把工作縮小。

例如，不是要求它「完成筆記功能」，而是一次只處理一件事：

請先檢查目前的程式，不要修改檔案，告訴我新增筆記需要調整哪些地方。

確認方向之後，再提出下一個需求：

這次只實作新增筆記，不要加入編輯、刪除或資料儲存。

這樣做可能比較慢，卻比較容易知道每一次修改的目的。

修改完成不代表可以直接接受

Codex 修改程式後，我至少需要確認三件事。

第一，這次改了哪些檔案。

如果原本只打算修改 JavaScript，結果 HTML 和 CSS 也一起出現大量變動，就要先確認那些修改是否真的有必要。

第二，修改內容有沒有超出需求。

我只要求新增一個功能，就不希望它順便重整整個專案。變動範圍越大，越難判斷錯誤是從哪裡出現的。

第三，我能不能用自己的話解釋主要程式。

我不一定能立刻說明每一個細節，但至少應該知道資料從哪裡取得、經過什麼處理，以及最後如何反映在畫面上。

如果完全說不出來，就表示這段程式目前還不算真正屬於我。

我希望 Codex 扮演的角色

我不想把 Codex 當成按一下就能交作業的工具。

它比較像是一位可以直接進入專案協助工作的搭檔：能讀取現有程式、找出可能需要修改的位置，也能執行指令和協助檢查錯誤。

但要做什麼、這次做到哪裡，以及最後是否接受修改，仍然需要由我決定。

接下來的開發，我會盡量遵守這個流程：

1. 先說明這次只要完成的功能。
2. 修改前先確認影響範圍。
3. 一次不要改太多東西。
4. 修改後查看程式碼差異。
5. 實際操作並確認結果。
6. 用自己的話記錄這次學到的內容。

我應該還是會有看不懂的時候，也可能為了趕進度，很想直接接受全部修改。

但至少從現在開始，「程式可以執行」不會是唯一的完成標準。

下一篇，我會實際選擇一個小功能交給 Codex，記錄我怎麼描述需求、它修改了什麼，以及我如何檢查結果。